GroupBy row select emit event once, perf #10493
Conversation
damyanpetev
force-pushed
the
dpetev/groupby-row-select-perf-event
branch
from
78a174b to
76efed7
Compare
damyanpetev
force-pushed
the
dpetev/groupby-row-select-perf-event
branch
from
76efed7 to
e70feeb
Compare
| @@ -463,11 +462,44 @@ export class IgxGridSelectionService { | |||
| } | |||
| const newSelection = this.getSelectedRows().filter(r => r !== rowID); | |||
| if (this.rowSelection.size && this.rowSelection.has(rowID)) { | |||
| this.selectedRowsChange.next(); | |||
There was a problem hiding this comment.
Removed multiple instances of sending new values to the subject before calling emitRowSelectionEvent. The latter will eventually reach and call selectedRowsChange.next() as well, but after the cancel check..
BEHAVIOR CHANGE: row selection even is now emitted only once for the entire group selected as intended. `added` and `removed` arrays in args contain all affected rows Closes #9250
damyanpetev
force-pushed
the
dpetev/groupby-row-select-perf-event
branch
from
e70feeb to
3fba870
Compare
mmart1n
added
💥 status: in-test
|
Scenario 19 has failed. When editing a selected row so that it goes to another group the row appears as not selected and the group-by row checkboxes are not handled correctly. If this is the only one selected row in the grid the header checkbox selector remains in indeterminate state. |
This issue is not introduced by this PR so it should be logged separately. |
mmart1n
added
✅ status: verified
Closes #9250
Related to changes in PR #10088; see after screenshot - the bulk of the remaining slow down was caused by the Group selector click handler spamming single selects with event emits for each. Per this #9405 (comment), with 30k-ish records in the group selection took a good 20s+ due to that.
Refactored two methods that do essentially the same as the single ones but in bulk and now the selection emits once but is also now decently quick. For comparison w/ the previous PR scenario:
Further, with 30k rows the click handler is in the 115ms range and acceptable 300ms for 100k rows (local dev run w/ profiler running), so it scales more or less linearly. Also being finally profile at higher count, the previously fixed
selectedRowsInTheGroupbecame the slowest link again, so further improved as well.Additional information (check all that apply):
Checklist:
feature/README.MDupdates for the feature docsREADME.MDCHANGELOG.MDupdates for newly added functionalityng updatemigrations for the breaking changes (migrations guidelines)